All DatabasesMacTech Vol 09-1993
Portability
Volume Number: 9
Issue Number: 10
Column Tag: Software design
Related Info: Memory Manager File Manager
Beyond the Macintosh
Here’s a way to design your code to be portable
By Lala “Red” Dutta, DataViz, Inc.
Here we are... 1993 and the playing field has narrowed down to a handful of
machines and architectures. The contenders left on the field are Unix boxes, PC’s and
Mac’s. However, soon to enter the playing field is the Power PC based Macintosh. And
where are we? Since the majority of MacTech readers are Macintosh programmers, it
is safe to assume... “We’re On A Macintosh!” (And I say that while making some Tim
Allen grunts)
But for a moment, let me state a few observations of mine...
• Macintosh programmers know what the game really is... “Make something
obvious and simple, and people will use it.”
• Wouldn’t it be nice if we could show the rest of the world how to write a better
application?
• Wouldn’t it be nice if we made lots of money selling this stuff to the
unenlightend?
So with those observations, let me ask the million dollar questions... Is your code
portable? Will you be able to recompile and run on the Power PC? And what about
Windows and OS/2? Can you recompile and run there too? After all, if you can do
that, you can make money on many fronts!!! (Mo’ Money, Mo’ Money, Mo’ Money!)
At this time, I want to make a couple of statements about what’s up and coming,
and what’s not! A lot of gratuitous code will not be present! After all, we’re all adults,
and we’re bright enough to code this stuff on our own! (We don’t need no stink’in
code!) You can also expect to see quotes from many movies and sitcoms. Also, even if
you’re not a techie, you should have no problem understanding the gist of what I’ll be
talking about (although a vague idea about C and C++ would help).
Zen And Portability
Before we can walk down the golden path, we need to have an objective. So here is
the line my co-workers are use to hearing me say...
If truly portable code is written, it can be used anywhere, any time, and in any
form.
So there’s the target we wish to hit. But now to get back to the real world, we
know we can’t hit that 100% of the time. So the true key is to separate what can hit
that target from that stuff which cannot. To get a little more specific, we need to
achieve the following:
• Create platform independent code that relies on other platform dependent code to
do the dirty work.
• Have uniform API’s between the platform dependent and independent code.
• Ensure that the platform independent code is completely insensitive to the
underlying hardware and operating environment.
• Ensure that the platform dependent code has a completely general interface and
takes full advantage of the underlying hardware and operating environment.
• Finally, ensure that portability is retained through maintenance.
Portability Overview
So what does this all mean? Hopefully, this diagram clears things up a little
bit:
With this type of model, your core code deals with doing the main task at hand. It
then relies on other code to take care of the platform specific stuff. So what kind of
things go in each group of code? It really is entirely your choice, but this happens to
be my model:
Environment Manager TApplication, InitApp, MaxApplZone
User Interface Manager TWindow, TLists, TButton, TStatic,
Referenced by (12):